Conventional database management systems receive queries from client applications and provide a result set to the client applications in response. Such queries typically conform to a query language (e.g., Structured Query Language (SQL)), and specify a data source (e.g., database table) and parameters describing the data to be included in the result set.
Occasionally it is desirable for the parameters to include tabular data. FIG. 1 illustrates an example of a conventional system for consuming such parameters. As shown, an example Query Client may include an Advanced Business Application Programming (ABAP) kernel, a Database Interface/Database Shared Library and an SQL Database Connector. The ABAP kernel includes an internal table (itab) stored in volatile memory (e.g., Random Access Memory) and which describes data to be included in a result set.
In one example, the ABAP kernel may begin with a query: 1*SELECT <result> FROM <table> FOR ALL ENTRIES IN itab WHERE . . . <col> <op> <itab_comp> . . . . In order to process the query, the ABAP kernel dissasembles the tabular itab into scalar values and passes these values to the DBI/DBSL as Query Parameters. After further processing by the SQLDBC, the resulting SQL statement generally appears as: N*SELECT <result> FROM <table> WHERE (col1, . . . , colM) IN (il1, . . . , iln), . . . ), and is passed to a Receive Buffer of a Data Server.
An SQL layer of the Data Server reconstructs the tabular data from the Query Parameters and an Engine executes the query using the reconstructed tabular data. As shown, execution of the query by the Engine of the Data Server requires an m*n search of the Target Table. Moreover, since the query was divided into N statements, the ABAP kernel performs up to N rows DISTINCT handling.
Systems are desired to efficiently determine entries of a target table which are associated with entries of a different table.